On a present telecommunications network, there are many complex network devices, such as routers, gateways, switches, firewalls, and various types of servers. These devices separately support various types of network protocols to implement interconnection and interworking between network elements. Each device includes an internal packet forwarding module and various types of protocol control modules. This distributed control module deployment manner makes network deployment and management very complicated. To implement modification or an upgrade of a certain control parameter, a network operator must perform operations separately on each device.
To achieve network element deployment flexibility and manageability, the software-defined networking (SDN) concept is raised in the industry. In the SDN, control logic and forwarding functions of network elements are decoupled and the control logic is deployed in a centralized manner, so that network control and maintenance work can be implemented simply by operating control-plane devices, thereby increasing network management efficiency and simplifying forwarding-plane devices to facilitate implementation of high performance and reusability of forwarding devices. Currently, the SDN idea is being widely applied to data center networks and telecommunications networks. The Openflow protocol is the most typical and most widely used protocol on SDN networks.
Network elements in the Openflow protocol include Openflow controllers (OF Controller, controller for short) and Openflow switches (OF Switch, switch for short), where, a controller is responsible for determining, according to packet characteristics (such as an IP 5-tuple, an Ethernet frame header, and a virtual local area network ID), forwarding actions (such as forwarding, discarding, modifying a packet header, encapsulating, and decapsulating) of a service flow, and delivering a corresponding flow rule (including flow matching information (such as an IP 5-tuple and an Ethernet frame header) and corresponding executed actions) to a switch. The switch acquires and stores the flow rule and executes corresponding actions for subsequent packets that comply with the flow rule, thereby implementing packet forwarding or processing. A basic process for delivering a flow rule is shown in FIG. 1a. 
In step 1, a controller sends a flow table entry to a switch by using a Flow_Mod (flow table modification) message, where, the flow table entry includes flow matching content (flow match) and corresponding processing actions (actions). The flow matching information includes a combination of any information of an Ethernet frame header, IP header information, and a TCP/UDP port number, and the processing actions include processing types and relevant parameters. Processing types are, for example, forwarding, discarding, modifying, encapsulating, and decapsulating. The controller may deliver flow table entries that belong to different flow tables to the switch by using multiple Flow_Mod messages. In FIG. 1a, the controller separately sends flow table entries of two tables to the switch.
Then, the step 2 is executed. That is, the switch stores (installs) all the flow table entries and the processing actions in corresponding flow tables.
After that, the step 3 is executed. That is, when a user packet arrives, the switch implements multi-level flow table matching and performs, according to the processing actions corresponding to matched flow table entries, serial processing on the packet. For the multi-level flow table matching and processing process, refer to FIG. 1b. 
First, a packet enters a switch from a certain input port, and the switch matches flow table entries of a table 0 (table0) against the packet first, and performs, after a certain flow table entry is matched, an operation on the packet according to an instruction of the flow table entry. If a flow table entry has multiple instructions, the instructions are executed according to a certain sequence (goto-table is executed last). If an instruction has Goto-Table, the packet and optional metadata are sent to a next flow table, the next flow table is further matched against the packet or metadata, and subsequent instruction processing is performed. If an instruction does not have goto-table, it indicates that exiting from the pipeline is needed, and the switch executes a processing action set of saving actions, where, the set includes actions such as packet modification, forwarding a packet to a certain port, or packet discarding.
In the prior art, to increase flow table entry addressing efficiency, a manner of implementing flow table entry addressing by means of metadata matching is provided, as shown in FIG. 1c. A controller generates various table entries matching metadata in a flow table 2. Write metadata instructions are added to table entries in a flow table 1. After a packet arrives, the packet is matched against the table entries in the flow table 1. After matching is successful, corresponding metadata and the packet are transmitted to the flow table 2. The flow table 2 is matched against the corresponding metadata. After matching is successful, corresponding instructions are executed.
However, the present applicant finds, in the process of implementing the technical solutions in the embodiments of the present application, that in the method in the prior art for implementing flow table entry addressing by means of metadata matching: one manner is implementing matching and searching by using metadata content, which requires dedicated hardware for implementation, and therefore the cost is relatively high; and another manner is implementing a hash (hash) operation on metadata to obtain table entry indexes in a next table, which requires an extra hash operation and in addition a solution to a hash operation conflict problem (hash operation conflict means that a same value is obtained after hash operations are performed on different metadata), thereby causing relatively low hash operation implantation efficiency (an extra hash operation) and complicated operations (extra processing is required when a hash conflict occurs). Therefore, in the prior art, there are technical problems of relatively low flow table entry addressing efficiency, relatively complicated flow table entry matching, and relatively high costs caused by use of metadata matching.